\section*{Run 2}
\subsection*{Modules to decompose}
The modules we are going to decompose in this run are the Incoming and Outgoing Communication Module. In the process we also create new level 2 modules to extend the functionality.

\subsection*{Choose architectural drivers}
\begin{itemize}
\item P1: Timely closure of valves
\item UC8: Send measurement
\end{itemize}

We chose P1 again as the driver for this run, with the addition of UC8. In this run the existing components will be refined more in detail. 

\subsection*{Choose architectural patterns}

Performance tactics (P1):
\begin{itemize}
\item Resource management: obviously increasing the available resources is a logical solution for this requirement, but this is more a hardware solution than an architectural solution. Only adding new hardware is not enough, therefore we chose to introduce concurrency. When multiple request can be handled in parallel, the blocked time can be reduced, resulting in a faster request handling.
\item Resource arbitration: A dynamic priority scheduling algorithm with earliest deadline first seems to be the best choice in our opinion. This way, gas alarms have almost always the highest priority, followed by water and then by power. Gas has a deadline of only 10 seconds so most of the time it will have the highest priority. With dynamic scheduling starvation is not possible, because deadlines always get shorter and the shortest deadline will always be chosen first.
\end{itemize}

Patterns

\begin{itemize}
\item Active Object: Since P1 needs concurrency and a scheduling algorithm the active object pattern seems to be a logical choice as a pattern. Not only will the alarms be handled concurrently, but also according to a dynamic scheduling principle.
\item Message Router: Because many different trames can enter the Incoming Communication Module, they need to be handled by different other components. A message router will take care of the routing to the different components.
\end{itemize}

\subsection*{Modules}

\begin{itemize}
\item Incoming Communication Module:
\begin{itemize}
\item Trame Validator: The trame validator check the trames for their validity. When a trame is not considered a valid trame, it is dropped and does not enter the system further (UC8 2b) .
\item Trame Buffer: the trame buffer is a buffer where all the incoming trames are kept. A buffer makes sure that a burst of trames does not necessarily become a problem, because the trames are buffered.
\item Incoming Trame Scheduler: This component will schedule the trames that are in the buffer according to their priority. Alarm trames have a higher priority than the other trames, so they are handled first.
\item Incoming Communication Message Router: The message router makes sure that the trames coming from the scheduler are passed to the correct component.
\end{itemize}
\item Data Processor: Measurement trames, configuration trames and perhaps other trames are passed to the data processor. The Data Processor will ask the command sender to send an acknowledge to the remote module for the received trame. For now nothing is done with these trames. This will change in the next ADD runs.
\item Outgoing Communication Module:
\begin{itemize}
\item Channel Selection Module: The channel selection module gets notifications as well as trames. For the notifications it sends them over the obvious channel, there is no further lookup necessary. The communication channel is already embedded in the notification. For the trames however it needs to call a Request Data to the Main DB component to know the communication channel for this trame.
\item Command Buffer: The command buffer is a buffer that holds all the commands that need to be send to the remote modules.
\item Outgoing Communication Scheduler: This is a scheduler that makes sure that important commands (e.g. close valve) are handled before less important commands.
\item Trame Builder: The trame builder receives a command from the scheduler and makes a trame of this command. The channel to send the trame is being handled by the Channel Selection Module.
\end{itemize}
\end{itemize}

\begin{figure}
  \centering
    \includegraphics[width=\textwidth]{addRuns/ADDRun2.pdf}
  \caption{Run 2: Level 2 and level 3 decomposition of the ReMeS system}
  \label{addRun2}
\end{figure}

\subsection*{Define interfaces}

\begin{center}
    \begin{longtable}{ | p{4cm} | p{3,5cm} | p{7,5cm} |}
    \hline
    Component & Interface & Operations \\ \hline
    Trame Validator & iTrameValidator & \begin{itemize} \item \textbf{receiveData(Data d)} \end{itemize}  \\ \hline
    Trame Buffer & iTrameBuffer & \begin{itemize} \item \textbf{add(Trame t)}  \item \textbf{take(Trame t)} \end{itemize}  \\ \hline
    Incoming Communication Scheduler & iIncomingScheduler & \\ \hline
    Incoming Communication Message Router & iMessageRouter & \begin{itemize} \item \textbf{add(Trame t)} \end{itemize} \\ \hline
    Channel Selection Module & iChannelSelection & \begin{itemize} \item \textbf{sendNotification(Notification n)} \item \textbf{sendTrame(Trame t)} \end{itemize}  \\ \hline
    Command Buffer & iCommandBuffer & \begin{itemize} \item \textbf{sendCommand(Command c)} \item \textbf{take(Command c)} \end{itemize} \\ \hline
    Outgoing Communication Scheduler & iOutgoingScheduler & \\ \hline
    Trame Builder & iTrameBuilder & \begin{itemize} \item \textbf{createTrame(Command c)} \end{itemize}      \\
    \hline
    \end{longtable}
\end{center}

\begin{figure}[h]
  \centering
    \includegraphics[width=\textwidth]{addRuns/IncomingCommunicationModule.png}
  \caption{Run 2: Interfaces of level 3 decomposition of the Incoming Communication Module}
  \label{incomingCommunication}
\end{figure}

\begin{figure}[h]
  \centering
    \includegraphics[width=\textwidth]{addRuns/OutgoingCommunicationModule.png}
  \caption{Run 2: Interfaces of level 3 decomposition of the Outgoing Communication Module}
  \label{outgoingCommunication}
\end{figure}

\begin{figure}[h]
  \centering
    \includegraphics[width=\textwidth]{addRuns/DataProcessor.png}
  \caption{Run 2: The addition of the Data Processor component to the second level decomposition}
  \label{dataProcessor}
\end{figure}

\subsection*{Verify and refine}
This Add run went more into depth of the different components. Problems with the previous ADD run are now partially solved. More specific are the schedulers implemented, so the incoming and outgoing trames can be scheduled as well as the validation of the incoming trames.
\begin{itemize}
\item UC8: Send Measurement. This use case needs to be refined more. The only thing that is being used from UC8 is that the Incoming Communication Module knows there are measurement trames and that they need to be routed using the Message Router to the Data Processor component. The Data Processor already has the ability to let the Command Sender know to send an acknowledge command to the remote module. The anomaly detection in this use case is not yet thought about and since this is not yet completed this needs to be refined more in the next run.
\item P1: timely closure of valves. The most important part in this requirement is that the alarm trames are being scheduled and have a high priority as well as the close valve trames. Alarm notifications can be send to the customer.
\end{itemize}

\paragraph*{Requirements that are now completely covered:}
\begin{itemize}
\item \textbf{P1: Timely closure of valves}
\item \textbf{UC8: Send measurement}
\item UC9: Notify customer
\end{itemize}

\subsection*{Remarks}
\begin{itemize}
\item The command sender only holds a record for the commands it sends. Not for the acks it has to send.
\item The Data processor sends an ack for every incoming trame. It does not need to hold a record of the incoming trames or the acks it sends. Double incoming trames can be checked by requesting the latest measurement from the database and comparing. This can also be solved when the trame is placed in the database. A little check is enough to know that the trame already exists in the database.
\end{itemize}
